[レポート] Creating flexibility & choice for VDI management w/Amazon WorkSpaces #EUC203 #reinvent
しばたです。
re:Inventのオンデマンド動画を漁ってたところ、Amazon WorkSpaces Coreに関するものを見つけたのでレポートを書くことにします。
動画
概要
Many organizations have existing virtual desktop infrastructure (VDI) solutions that they want to migrate to the cloud or expand into a hybrid environment that uses both cloud and on-premises resources. In this session, learn about options to create a consistent end user and administrator experience that spans both on-premises and cloud-based VDI deployments.
セッション内容
タイトルや概要を見る限りだと単純に「オンプレVDIからクラウド環境へ移行するのにAmazon WorkSpacesを使おう!」って感じの内容かと思っていたのですが、実際に視聴すると結構な割合でAmazon WorkSpaces Coreについて語っており、むしろAmazon WorkSpaces Coreを紹介する方が主なのでは?と感じるくらいの内容でした。
VDI環境のマイグレーション
最初はVDI環境のマイグレーションに関する一般的な話から。
参加者に簡単なアンケートを取りつつ、主にオンプレVDI環境を想定したシステム更改やマイグレーションに関して
- 環境を変えることによるユーザー教育コスト
- 同様に管理者の勉強コストも
- ワーストケースを考えてオーバーキャパシティになりがち
- 数年後のカットオーバーのために今ハードウェアを調達するつらみ
と言った話題に触れてました。
セッション中ではこのほかにTCO削減まわりの話もそこそこありました、が、若干セールストークな感じだったのでほどほどに受け止めておくのが良さそうです。
AWS WorkSpaces Core
VDI環境のマイグレーションのつらみに触れつつAmazon WorkSpacesの利用に話は変わっていくのですが、このセッションではいきなりWorkSpaces Coreを紹介してきます。
サービス公開時に紹介した様にWorkSpaces CoreではAWSはインフラ管理のAPIを提供しVMwareといったサードパーティーがWorkSpaces基盤を使いVDIを提供するのとなります。
WorkSpaces Coreのサービスとしての立ち位置としては下図の様に「Amazon WorkSpacesを使う」のと「クラウド環境に自前でVDI環境を構築する」の中間にあるとのことでした。
WorkSpaces Coreのメリットしては主に以下の点を挙げていました。
- (WorkSpace Core APIをベースとした) 高速なデプロイ
- (サードーパーティVDIで) 統合された管理
- (AWS基盤の従量課金による) コスト最適化
このほかにも
- 運用はEC2のプロであるAmazon EUC Team
- AWSを使うことによるキャパシティマネジメント
と言った点も触れていました。
どこまでマネージドにするか?
各種VDI環境において管理対象となる範囲を示した以下の表が参考になるので共有しておきます。
「VDI control plane install and admin」がカスタマー(orパートナー)管理となる点がWorkSpaces Core最大の特徴です。
デモ
WorkSpaces Coreの実装として、今現在はVMwareとHorizon 8向けのインテグレーションを開発しているそうです。
セッションの最後でVPC環境にVMware Horizon 8のコントロールプレーン(Connection ServerとUnified Access Gateway)用意した環境でのデモが行われています。
デモ環境の詳細は以下の通りです。
- 認証のためにAWS Managed Microsoft AD環境を用意
- クイックスタート構成 (AWS での Active Directory Domain Services の シナリオ3) で環境を作ってる
- AD Connectorも使えるとの事
- RDSについてはあまり説明が無かった
- ただ、イベントデータベース用DBの模様
この環境に対して、
- 最初にVM ExportとVM Importを使いWindows 10イメージをAWSに登録
- ※セッション中では触れられませんでしが、Windows 10をAWS環境で使うにはライセンス上の制約があります。WorkSpaces Coreであろうが特別扱いはされないハズです
- このAMIをWorkSpaces Coreにインポート
- BYOL かつ BYOP(Bring your own protocol)
の手順でWorkSpaces環境にイメージを登録。
BYOPで登録しているのがポイントですね。
AWS CLIのコマンド自体は以下の様にごく普通のもので、今のバージョン(Ver.2.9.10)に存在するオプションでした。
# コマンドは普通のAWS CLI。今でもこの形式のコマンドは使える
aws workspaces import-workspace-image --ingestion-process BYOL_REGULAR_BYOP
インポートされたイメージをベースにしてバンドルの作成→利用者向けWorkSpaceの作成を実施。これはWorkSpacesのいつもの流れです。
そうして作成されたWorkSpace(DESKTOP-FO4546O
)ですが、これがHorizon側にも登録され利用可能になります。
(DNS名 desktop-fo4546o
が一致しているのがわかる)
後はHorizon側でこの仮想マシンのデスクトップ登録+エンタイトルメント設定してやると、
Horizon Clientから利用可能になりました。
デモはこれで完了です。
インフラ管理者の立場では
- Amazon WorkSpacesにWorkSpace環境を作る (これでHorizonからは仮想マシンとして参照可)
- Horizonから仮想マシンを展開する
という流れになり、利用者の立場では
- いつものHorizon Clientをそのまま使う
という形になることがわかりました。
利用者にとってやることが従来通りというのはたしかに魅力的ですね。
最後に
以上となります。
VDIの移行としては割と普通の内容でしたがWorkSpaces Coreの動作イメージを掴むのに非常に参考になりました。
インフラ周りのより詳細な情報については以下のブログ記事をご覧いただくと良いでしょう。(セッション中で紹介されています)
加えてこちらの動画も一部内容は被りますがおススメです。